As an important methodology, web service provides a way to realize loosely coupled service-oriented architecture and interoperable solutions across heterogeneous platforms and systems. Web services are well suited for integrating disparate enterprise systems, particularly those having evolved over time. By enabling existing enterprise resources through web services, these enterprises can be expanded to provide services to a wider variety of clients.
Web services are constructed around a set of standard protocols, such as WSDL, SOAP, and UDDI (described below). In particular, WSDL (Web Service Description Language) is an XML-based language for describing the services. It contains information pertaining to the service description of Web services, such as the interface, the service operations, the data type schema information, the parameters required to invoke the Web service, etc. It provides the message level coupling between various components in a service-oriented system.
Simple Object Access Protocol (SOAP) is a standard protocol for exchanging XML-based information over the network. It provides a platform independent way to access and utilize Web services located on different distributed systems,
UDDI (Universal Description, Discovery, and Integration) defines a format for discovery as well as a protocol for retrieving the discovery document. It provides a registry mechanism for clients and servers to find each other.
Traditional web service interaction is based on one-way request/response interaction pattern that a client (e.g. service consumer) makes a service request to the server (e.g. service provider) based on the services specified by the server's WSDL. The server responds with the requested service to the client in its positive response SOAP message. Otherwise, a fault message will be sent from the server to the client. It only requires one WSDL at the server side to conduct the interaction. Albeit being simple, it has been extremely useful, because it is well suited for the Internet infrastructure and the WSDL based service description is extensible and self-describing.
Two-way web service interaction is a new trend in web services, motivated by the critical needs to support asynchronous outbound web service operations, event subscription/notification, service grids, communication, etc. In two-way web service interaction, each web service SOAP node is both a client and a server, and it requires two appropriate WSDLs, one at each web service SOAP node to conduct two-way web service interaction. One typical use of two-way web services is for event subscription and notification, in which the client needs to submit a request to the server to subscribe events from an interested source at the server. In client-to-server web service interaction, the client must specify an appropriate event sink described by its WSDL for server to push events to the client through a server-to-client web service interaction. For example, when the subscribed event occurs at the server, the server will proactively send the event to the client event sink acting in a role of a client.
When deploying web services for enterprises, there is an acute need to allow web services to cross different enterprise network domains of firewalls/NATs, because the very nature of web services is to integrate disparate enterprise systems located at different enterprise domains, or even at different enterprises. Branch offices and mobile workers need to interact with headquarters through web services, and enterprises need to communicate with their suppliers, partners, etc., through web services to enable their business process.
While one-way web services crossing enterprise domains is less a problem, adopting two-way web service (or any asynchronous web service) interaction will face serious problems when it comes to cross enterprise domains and firewalls. This is because enterprise networks are typically protected by network address translation (NAT) devices and strictly configured firewalls. NAT hides the enterprise (internal) network addresses from the public Internet, allowing multiple computers inside the enterprise networks to share a (or a group of) public addresses, and also providing protections to the enterprise networks by limiting the access of the external computers into the enterprise networks.
A firewall is a system or group of systems that enforce access control policies between two networks. Firewalls are designed to prevent unauthorized access to or from an internal network. NAT/firewalls shield enterprise (internal) networks by blocking the incoming traffic initiated from the public (external) network and opening only limited ports for outgoing traffic, such as HTTP port 80. The NAT/firewall can be a showstopper for asynchronous (two-way) web service interactions between two computers that are located in two separate networks. This is because 1) both networks are behind their own NAT/firewall, and thus the IP address of the service is not addressable/routable outside the private network; and 2) in most cases, NAT/firewalls block the incoming traffic, thus the computer in one network cannot reach the other one that located in another network.
One common practice to address this problem is that enterprises expose the service to the external clients by changing their network NATs/firewalls configurations. For one-way web service, only the service provider (server side) needs to expose the service interface, and service consumers (client side) do not need to do anything. For the two-way web services, it requires both the service provider and service consumers to expose their service interfaces to be addressed from external network. Since enterprises deploy sophisticated security infrastructure and stringent access control measures, IT network administrators are highly resistant to any attempt to reconfigure their NAT/firewall. Before changes can be considered, it has to go through a lengthy review and approval process. Maintaining and servicing these special service openings on the NAT/firewall can be an exorbitant task, and it is definitely not for dynamic changes for on-demand services. But most importantly, practices from prior arts for one-way web services cannot be applied directly to two-way web services, because of serious security issues that causes both clients and service providers to expose excessive internal interfaces to external networks.
Another practice to address this new demand for two-way web services is to deploy a virtual private network (VPN) to link disparate networks together. However, VPN is very expensive and complex. Moreover, enterprises do not allow other enterprises, their partners or suppliers to access their internal enterprise networks through VPN directly because of privacy, security, and protection reasons.
For the past few years, extensive studies on NAT/firewall traversal have been carried out at both academia and industry. However, there is still no single solution which is flexible enough to work well in the two-way web service scenario. For example, Simple Traversal of UDP through NAT (STUN) can solve some of NAT issues, however, it will not work with Symmetric NAT which is often found in the networks of large enterprises. Traversal Using Relay NAT (TURN) solves this by using relay, however it assumes peer-to-peer connectivity. It is not suitable for a client to use the STUN relay server to run a traditional server. Interactive Connectivity Establishment (ICE) tries to uses both of them in a specific way to avoid the pitfalls of using any one of them alone. However, it is not a new protocol from the communication protocol perspective. And all the above methods try to solve NAT/firewall issue for Voice over IP (VoIP), and they don't address the special requirements in web services applications. Another problem is the scalability issue, which makes the above methods impractical in the two-way web service scenario. Most importantly, these methods and studies did not take into account the two-way web service nature that requires matching WSDLs at each service end and SOAP message exchange in two-way, full duplex interaction.
Sockets (SOCKS) is an Internet protocol that allows client-server applications to transparently use the services of a network firewall. SOCKS and SOCKS based products form another category of widely used NAT/firewall traversal approaches. It allows servers on each side of a network barrier to communicate with each other. It is often used as a firewall that straddles the network barrier and permits the communication. However, SOCKS is not suitable for the two-way web services because both client and server are typically behind their own firewalls. In such situation, the address in the protocol the SOCK's server passed to the destination will become un-routable. Moreover, although SOCKS can be used to allow the clients outside the firewall (“exterior clients”) to connect to servers inside the firewall (internal servers), it allows only one exterior client with the specific IP address/port to connect to another application that is on the internal server. This is not suitable for two-way web services, where there are multiple servers and clients and IP addresses, service ports, etc., can all be dynamic.
One study related to firewall traversal for web service SOAP messages is the work of Web Service Dispatcher (WSP) system. It uses WSP as an intermediate service that can forward SOAP messages and assist asynchronous message exchanges. It addresses the client side NAT/firewall issue by setting up a WS-MsgBox service at the WSP dispatcher. It receives and stores the service responses for the client, whereas the client needs to fetch the responses from WS-MsgBox regularly for messages. Although the WSP system probably is able to solve the NAT/firewall traversal problem for normal one-way web service interaction, it is not suitable for two-way web service interaction, e.g. those used in telecommunication, because the “pulling” scheme is too slow to satisfy the real-time communication requirement.